查看原文
其他

用“柔性”应对“变化”:什么样的集成平台才具有“自我进化力”?

陈曦 HIT专家网官微 2024-01-09

导读

在集成平台能力持续进化的进程中,医院的“多面化”需求通过更柔性的集成架构得以实现,使得集成平台在医疗场景中呈现“百花齐放、各有特色”的应用新局面。

集成平台在医疗行业的建设逐步深入,新的问题也随之而来。

  • 有的医院发现,现有集成平台具备的数据交换技术如集成引擎、ESB等)和功能比较单一不能完全满足医院实际需求;
  • 有的医院在进行平台选型时遇到各种新名词,如微服务架构云原生、PaaS无所适从、难以抉择
  • 医院信息化建设“年年上台阶”,有的医院上线集成平台心里也不踏实,担心平台缺乏前瞻性短期内被淘汰,投资打了“水漂”

在这些困惑、犹豫、担忧的背后,实际隐藏的问题是:在医院数字化转型的行业背景中,在技术与应用的相互促进下,与几年前相比,无论是集成平台的自身能力,还是医院集成平台的应用场景已经发生了很大的变化。

技术与需求都并非一成不变。那么,什么样的医院集成平台才能具备“自我进化”的能力,更好地适应已发生和未来将发生的种种变化,从而帮助医院CIO们放下心中的疑虑与担忧?

Odin认为,这格外考验作为集成平台核心的集成中间件的能力。集成中间件必须具备“柔性化”的能力,不断实现功能架构的演进,从而更好地适应医院“多面化”的建设需求。

集成平台架构为何需要“柔性化”?

在医院数字化转型进程中,更加多样化、复杂化业务场景的出现,使得单纯技术导向型、能力“刚性”的传统集成平台渐显力不从心。“柔性化”成为新型集成技术架构演进的新趋势。

所谓“刚性”,是指以单一的集成技术解决某一类型的集成问题,让需求实现被动地去适应技术,能为用户发挥的作用和价值有限,也限制了医院信息化水平的提升。

比如,当下医院集成平台建设需要兼顾可用性、性能、效率、同步性、数据互操作等多方面问题,但受到IE(集成引擎)、ESB等数据交换技术自身特性的制约,传统的集成平台有些只能满足高可用和数据互操作需求(如基于IE技术实现的双活架构),有些只能满足性能和数据同步性需求(如基于ESB技术实现的多机多活架构),难以同时满足上述所有需求。

而“柔性”,则是指以集成场景和业务需求为导向,以业务价值输出为目标,通过多种集成技术的高效有机协作,从而实现全场景的覆盖。集成平台的柔性化能力不仅能很好地满足基础的互联互通需求,也能为不同场景下的数据利用打下扎实基础,成为支撑医院数字化转型的新“地基”。

在医院数字化转型进程中,技术实现的“柔性化”是非常重要的。比如,在保证院内以及跨机构协同时的数据互联互通方面,要实现这一点不难,但要做好做精,将数据互联互通从面上的数据标准融入实际业务场景却不容易。若是集成平台过于“刚性”,难以应对大量的复杂场景,导致数字化转型的“地基”不稳,后续在实现数据驱动业务、借助数据辅助决策的过程将举步维艰,这也是目前大部分医院数字化转型中的难点。

集成平台的“柔性化”架构,主要体现在以下几个方面:

首先,具备多种集成技术,功能可扩展。医疗场景越发复杂,即使是同一场景下,根据业务需求的不同,需要用到不同的集成技术或平台功能。因此,医院集成平台需要灵活运用多种集成技术,协同解决当前问题。同时还需具备可扩展的功能,以应对未来更加多元化的场景需求。

其次,以面向场景的微服务技术架构为核心。新版互联互通标准化成熟度测评方案在“3.1.2信息整合技术”条目的备注中提到:在总线技术基础上,可进一步探索基于微服务架构的环境搭建。

第三,平台负载和性能可延展,稳定高可用。集成平台的能力越强大,承载的业务类型越多,隐含条件之一就是负载、容灾的性能需要足够支撑,需要通过合理的功能和架构设计保证平台的高性能和高可用。

最后,产品具备平滑升级能力,伴随医院共同成长。想要实现投资复用,集成平台需要具备和医院共同成长的能力,从架构、管理、功能等多方面,根据医院成长不断进行升级调整,避免医院在集成平台建设中由于平台性能、稳定性、功能不如预期而陷入“打补丁”困局。

Odin认为,“柔性化”使得医院可以把更多的精力投入到业务目标的实现(以业务场景为导向),而无需过多考虑集成平台到底能做什么(被局限在技术实现手段上)。提高平台的设计规划能力和业务价值体现,降低底层技术实现的感知,是“柔性化”架构的重要目标。

那么,Odin是如何打造集成平台的“柔性化”能力?

功能上,Odin集成平台中间件具备IE、ESB、ETL、MQ、APIs等多种集成技术,并能合理依据业务场景进行灵活使用,还能根据医院的本土化需求预置功能;开放式、模块化的平台架构也能根据用户需求便捷地增加新功能、新工具,实现医疗业务全场景覆盖。

同时,Odin引擎集群版还内嵌智能熔断、自修复、定向隔离负载、精细化故障转移等技术,在出现某个项目对内存过度占用的情况时,能及时熔断并实现自修复,防止异常情况进一步扩散导致服务宕机,保证高可用。

架构上,Odin引擎集群版在产品设计之初,就根据医院集成平台的业务特点,原生实现了集群架构,而非单机系统部署在多台虚拟机上形成的“集群”(其核心仍是单机架构)。Odin引擎集群版分离了管理监控、生产服务、数据存储等功能,利用负载均衡构建集群体系,通过按需的横向扩展提升整体性能。

同时,Odin集成平台中间件以医院的场景化需求为核心,积极尝试各类功能与新技术、新架构的融合。比如,Odin引擎集群版借助容器技术和API网关,实现业务细粒度分割和独立的开发、部署,帮助外部系统构建微服务架构,达到业务级的微服务;而Odin云原生平台Odin NeXT更进一步,在设计时就将Odin的服务功能进行物理切割,实现了自身架构级的微服务。

医院的数字化转型是一个长期过程,针对医院不同阶段的实际需求,Odin提供从AO企业版到集群版再到Odin NeXT云原生平台的三个产品解决方案,平滑的升级能力可以为医院的长期建设规划持续提供技术支撑。

“柔性化”集成技术让医院集成平台应用实践百花齐放

从医院应用的角度来看,由于所处发展阶段不同、信息化建设基础不同,各家医院对于期望借助集成技术解决的场景需求也不尽相同,正呈现“多面化”的新特点。 

当作为“系统集成和互联互通应用”使用时,有的医院将其作为多院区同品质医疗、同质化管理的“数字基座”,借以支持跨院区、跨机构的业务协同,或是将需求量庞大的自助机业务、互联网医疗业务都纳入平台进行承载。例如,李惠利医院基于集成平台实现了跨系统、跨院区的互联互通,核心业务包括跨院区预约挂号、检查预约、会诊、预约住院、自助打印、治疗、转科、化验等深度协同服务,从而解决“两院融合”进程中的业务协同难点问题。

有的医院希望能将集成平台作为实现服务注册、订阅、发布、监管等面向服务的“业务中台”。例如,安徽某龙头三甲医院利用集成中间件打造财务中台,从不同系统集成财务运营相关数据,并与当地市局的财务平台进行对接,打通医院财政数据上报反馈、电子票据验证等财务服务的必要流程,加速推进了结算环节的无纸化与自动化。

更有医院希望能将集成平台作为跨系统的“低代码开发平台”。这类医院的信息部门通常具备较强的开发能力,日常工作中经常需要满足部分小型、微型信息化开发需求。在疫情期间,台州医院就利用集成平台的这种“低代码开发”能力,通过图形化拖拽式操作,结合丰富的数据处理组件,进行高效开发,实现了“健康码”应用1小时上线

基于“多面化”的应用场景与需求,与集成平台中间件“柔性化”的能力支持,已经有越来越多的医院利用集成平台满足了多样化、差异化、个性化的信息化建设需求。

不妨看看走在行业前列的医院利用Odin的“柔性化”集成技术都做了什么工作?

项目管理。“目前我们用集成平台主要做三类事情:项目管理、对外交互,以及数据上报。在项目管理中,我们在平台上监控各个项目的交互情况和交互量,这在技术上是很有意义的一件事情。”浙江省台州医院信息中心集成平台项目负责人刘祉呈如是说。

数据质控。“集成平台在质量控制中能发挥很大的作用。”郑州人民医院信息化建设和研发部主任兼数据中心主任张司露认为,不能把集成平台局限在“数据的搬运工”这一角色上。在建设集成平台时,郑州人民医院首抓的核心工作是“注入灵魂”,也即建立“主数据管理系统”,并交由各业务管理部门维护,信息中心的作用是提供好用的工具,帮助各部门通过集成平台控制数据的生产源头,并进行事中的闭环监控与事后分析,实现数据质控效果。

内控合规。据中信泰富医疗信息化负责人介绍,由于中信泰富的央企背景,需要构建“强内控、防风险、促合规”三位一体的内部控制体系,他最为看重的集成平台功能是基于大规模的数据集成,让集团总部了解各医院的经营情况并进行战略调整,同时基于平台打通经营管理全过程,形成管理闭环,从而更好地满足内控要求。

类似的应用实践还有许多。在集成平台能力持续进化的进程中,医院的“多面化”需求通过更柔性的集成架构得以实现,使得集成平台在医疗场景中呈现“百花齐放、各有特色”的应用新局面。

近期热文
HIT专家网∣致力推进中国卫生信息化长按二维码可申请加入HIT专家网专业交流群

寻求“商务合作”,长按二维码可快速与我们取得联系


投稿:gong_chen@HIT180.com

商务合作:(010)82373062


本公众号原创文章,版权归HIT专家网和原作者所有。

未经许可,谢绝转载或以其他形式使用文章内容进行传播。


继续滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存